Cynefin framework, Edwin Stoop
In my first story ‘User Experience is …’ I promised that …
"over the course of a few stories, I’ll try and cover a few of the sciences we draw upon in our art as a creative community to create engaging experiences."
Previously I’ve talked around how User Experience is … Product Ownership and how UX and product management both play an important role in bringing products to market.
Product development always involves dealing with a certain amount of unknowns. Either as a total team or purely as individuals. Something could be completely new for everyone, or maybe it’s only new for some of the team. In both cases there are still an amount of unknowns.
A great way of thinking about uncertainty and unknowns is the Cynefin framework.
Cynefin framework, Edwin Stoop
Analysing third party systems, investigating new standards and assessing risk of migration to a new version of an infrastructure component are all common tasks to do at the start or during building a product.
But these tasks differ from others of the same type enough that people can’t really estimate them without digging into them and starting to understand them a little.
And so stories involving these tasks are almost impossible to plan for effectively. Without knowing at least roughly what needs to be done, nobody can accurately predict how long it will take to implement.
Such vague stories often introduce a lot of variability into the delivery process and the short-terms statistical analysis that you would use for regular work won’t really apply to planning such stories.
In iterative processes where team commit at the start of an iteration to delivery stories, such vague stories can lead to nasty surprises towards the end.
Extreme programming Dilbert by Scott Adams
Some teams solve this by writing fake user stories, that mostly follow the pattern:
‘As a developer
I want to understand how the new external API works
So that I can use the API’
They are rarely expressed in a way that would make them appear as valuable from the perspective of the user or business stakeholders. It’s almost impossible to define any kind of acceptance criteria for such stories.
A good way to deal with such situations is to explicitly split the research tasks into a separate story with a goal of its own. A helpful way of thinking about this is that a story should be either about learning or earning:
The big difference between a learning and a research task is that the story has an explicit goal. The goal should be valuable to a stakeholder and providing enough information so they can make a planning decision. The acceptance criteria for learning stories is easy to specify. You need to work with the stakeholders to identify what kind of information they need to in order to understand and then approve or reject the work. Then decide how much time the stakeholders want to invest in getting the information, effectively time-boxing the learning story.
Danny Virgil, Dual-track design sprints
Planning for time-boxed learning stories avoids research turning into vague, uncontrolled and partially implemented work, that introduces variability.
It also removes the need for research outside the regular delivery cycle preventing long upfront analysis.
Having explicit learning items helps to manage short-terms capacity and prevents overloading a team with other stories. This is particularly important for teams who track velocity with numerical story points.
When the learning and earning aspects of stories are split, teams don’t have to pretend to estimate learning, or to create user stories with no apparent value. At the same time, this idea also opens up the possibility that learning ends without a clear conclusion, or event with a decision that implementation would be impractical. This prevents nasty surprises for stakeholders, because a team only commits to the learning aspect of the story and not committing to delivery something vague.
Create a clear time budget for learning stories, how big depends on the important of the information you’re trying to get. This helps you to balance learning stories against earning stories. It will prevent learning-only iterations where nothing useful gets built, and stop the team from spending too much time solving difficult problems that potentially don’t need to be solved. If the learning story ends up without a clear solution the stakeholders can decide if they want to invest more time in learning or try and alternative solution path.
Get the team to decide on the output of a learning story before starting. What kind of information do stakeholders need for future planning? How much details and precision do you need to provide? Will a quick and dirty prototype be needed to validation the solution with external users, or is a list of key risks and recommendations enough?
This ensures that everyone is on the same page and help you decide who needs to be involved in the research.
Ideally, learning stories should be tackled by cross -functional delivery teams who will later implement the recommendations, not by separate groups. This avoids the need to create documentation, hand work over or transfer knowledge. After all these stories are all about providing certainty for the team.
Finally in ‘practices for scaling lean and agile development’ Larman and Vodde warn against treating normal solution design as fake research work, especially if it leads to solution design documentation for other people to implement. They suggest that research tasks should be reserved for ‘study far outside the familiar’
I mentioned in a previous story that there are some established approaches to provide certainty to engineering teams, so they’re able to make decisions on what to build and how to build it. Based on the knowledge that we know at any point in time. But in order to provide this certainty we need to be able to collaborate, have conversations and confirm concepts. The 3 C’s of agile, so potentially might use one of these approaches:
As it’s approaching Christmas I’m going to take a break and reflect. There might be a story that comes out of these reflection, so I’ll be back in the New Year. Over the Festive break I helped my parents by running tech support and reflected ... when did we make digital so difficult?
Originally written as part of the ‘User Experience is …’ series for UX Collective.